Skip to content

Update Python to 3.13.3 and add support to Windows on ARM64. #1477

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
May 28, 2025

Conversation

juj
Copy link
Collaborator

@juj juj commented Oct 18, 2024

Update Python to 3.13.0 and add support to Windows on AMD64. Rewrite packaging of pywin32 because it is no longer shipped via separate binary installers, but has migrated to use pip.

@juj juj force-pushed the update_python_to_3.13.0 branch from 4662f05 to eacc02c Compare October 18, 2024 21:55
@juj juj force-pushed the update_python_to_3.13.0 branch from eacc02c to eea63b9 Compare October 18, 2024 21:59
@sbc100
Copy link
Collaborator

sbc100 commented Oct 18, 2024

I guess to perform that actual upload I should download this PR and run the update script?

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm % comments

juj added 2 commits May 24, 2025 18:57
…packaging of pywin32 because it is no longer shipped via separate binary installers, but has migrated to use pip.

Python 3.13.0 has bumped minimum macOS version to macOS 10.13
@juj juj force-pushed the update_python_to_3.13.0 branch from 20a91ae to 4094acb Compare May 24, 2025 16:04
@juj
Copy link
Collaborator Author

juj commented May 24, 2025

Oh crud - I forgot to work through to land this.

Updated this PR now to latest 3.13.3. @sbc100 would you be able to take a new look?

Are you able to populate Google CDN with the needed zip artifacts? I presume those will have to be rolled first before landing this?

@juj
Copy link
Collaborator Author

juj commented May 24, 2025

If it helps, I can also generate the artifacts and upload them to my dev box for you to pull?

@juj
Copy link
Collaborator Author

juj commented May 24, 2025

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be arm64 instead of amd64 in the PR title?


Raspberry Pi Debian 12 (Bookworm):
1. Before calling this script, run "sudo apt install libssl-dev", or otherwise
Python won't be able to use SSL.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why add these instruction about linux if this script is only designed to run on mac and windows?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I must say I don't remember anymore - I may have tried to make emsdk work on Linux on ARM as well, and given that Raspberry Pi was the only ARM Linux device I hard around, I probably used that... and then banged my head against trying to figure out what's going wrong with it.

I can delete this though.

@sbc100
Copy link
Collaborator

sbc100 commented May 27, 2025

@juj juj changed the title Update Python to 3.13.0 and add support to Windows on AMD64. Update Python to 3.13.3 and add support to Windows on ARM64. May 27, 2025
@juj
Copy link
Collaborator Author

juj commented May 27, 2025

Should it be arm64 instead of amd64 in the PR title?

Err, it totally should. :) Updated.

@juj
Copy link
Collaborator Author

juj commented May 27, 2025

Don't we need the macOS binaries too?

Yeah, I can generate those in a moment.


upload_base = 'gs://webassembly/emscripten-releases-builds/deps/'


# Detects whether current python interpreter architecture is ARM64 or AMD64
# If running AMD64 python on an ARM64 Windows, this still intentionally returns AMD64
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand the second part of this comment.

Do we really want to report AMD64 if we are running amd64 python on arm64 windows?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is important because if one is running an Intel x64 version of Python (e.g. under Rosetta on Mac), then pip will install x64 versions of tools, not ARM64. So then the packager would accidentally pip install x64 versions of tools, but output an -arm64 artifact name.

So in terms of packaging, we should only report ARM64, if truly running on ARM64 version of the interpreter, to avoid any chance of mistake.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, so effectively this script cannot cross build the arm64 python package.

@sbc100
Copy link
Collaborator

sbc100 commented May 27, 2025

I don't understand how that CI can be passing here...

@juj
Copy link
Collaborator Author

juj commented May 27, 2025

Oh, I needed to bump mininum macOS version from 10.13 to 11.0, or ctypes would no longer compile on x86 Apple Macs.

10.13 macOS supported:

Laptops: MacBook (Late 2009 or later), MacBook Air (Late 2010 or later), MacBook Pro (Mid 2010 or later)
Desktops: Mac Mini (Mid 2010 or later), iMac (Late 2009 or later), iMac Pro (2017) (macOS 10.13), Mac Pro (Mid 2010 or later)

Whereas 11.0 macOS requires at minimum:

Laptops: MacBook (Early 2015 or later), MacBook Air (Mid 2013 or later), MacBook Pro (Late 2013 or later)
Desktops: Mac Mini (Late 2014 or later), iMac (Mid 2014 or later), iMac Pro (2017), Mac Pro (Late 2013 or later)

At Unity we have required macOS 11.0 as the minimum target since Unity 2023.2 that was released in November 2023, for macOS for both Arm and x64 Macs. (macOS 11.0 was the first macOS version that shipped with Arm support)

@juj
Copy link
Collaborator Author

juj commented May 27, 2025

I don't understand how that CI can be passing here...

Does the CI run the update_python.py script?

@sbc100
Copy link
Collaborator

sbc100 commented May 27, 2025

I don't understand how that CI can be passing here...

Does the CI run the update_python.py script?

No, but I would expect them to try to download the latest SDK which should now be pointing a non-existent (at least not yet) python archives.

Does ./emsdk install latest install your new python?

@sbc100
Copy link
Collaborator

sbc100 commented May 28, 2025

I uploaded the new binaries to cloud storage

@sbc100
Copy link
Collaborator

sbc100 commented May 28, 2025

Is there some where we need to update the new macOS min version? Otherwise this looks ready to land.

@mcbarton
Copy link

After this is in can I access this change by using emsdk install latest, or do I need to wait for the next release? I recently added a Windows x86 Emscripten build of a project called CppInterOp, and am interested in extending it to build on Windows arm too (mostly just to give developers the opportunity to build the Emscripten build from any platform they might have access too)

@juj
Copy link
Collaborator Author

juj commented May 28, 2025

Is there some where we need to update the new macOS min version? Otherwise this looks ready to land.

Updated CMake configure step to also target macOS 11.0 at minimum.

@juj
Copy link
Collaborator Author

juj commented May 28, 2025

After this is in can I access this change by using emsdk install latest, or do I need to wait for the next release?

After this lands, all releases will start using Python 3.13.0.

am interested in extending it to build on Windows arm too

You will be able to target native Windows on ARM support by locally installing emsdk install sdk-main-64bit on an Arm64 system. That will then download and build a fully Arm native toolchain from source.

The automatic releases build that Google's CI crunches out do not yet at least produce Windows on ARM prebuilt releases. That is a later conversation for Google to ponder when it would be a good time to start generating those.

@juj juj requested a review from sbc100 May 28, 2025 20:04
@@ -350,13 +388,13 @@
{
"version": "main",
"bitness": 64,
"uses": ["python-3.9.2-nuget-64bit", "llvm-git-main-64bit", "node-20.18.0-64bit", "emscripten-main-64bit", "binaryen-main-64bit"],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can also delete the python-3.9.2 entries in this file

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we did that, then people cannot manually choose to install the previous python 3.9.2 to e.g. compare if updating python to 3.13.3 was the root cause of a regression.

i.e. with retaining that, users can still install combinations of the individual tools that they like.

Copy link
Collaborator

@sbc100 sbc100 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm % comments

@juj juj merged commit d07c793 into main May 28, 2025
12 checks passed
@juj juj deleted the update_python_to_3.13.0 branch May 28, 2025 20:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants